Internet Protocol (IP) and Multiprotocol Label Switching (MPLS) Fast Reroute (FRR) technologies address the problem of slow convergence of routing protocols across networks. The conventional approach is to switch traffic from the primary path to a prepared backup path when network failures occur. In existing technologies, such as Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (ISIS), Label Distribution Protocol (/LDP), Loop Free Alternate (LFA) FRR, Border Gateway Protocol (BGP) FRR, Prefix Independent Convergence (PIC), network information is gathered with the help of a routing/signaling protocol and subsequently, backup paths necessary to prepare for failures of adjacent links or nodes are computed, and pre-provisioned in the forwarding plane. With help of this information, the forwarding plane is able to react to a failure event by switching from a primary to a backup path without waiting for the routing protocol to gather updated network information and for it to reconverge. Multi chassis solutions implementing Multi chassis Link Aggregation Group (LAG) in Active—Standby configurations exist as well, allowing one of the chassis to redirect traffic to the other quickly when a failure occurs.
A routing system consists of 1) an entity for managing the Routing Information Base (RIB), herein referred to as a RIB, 2) routing protocol entities, herein referred to as routing clients, and 3) forwarding entities. Routing clients manage routes, derived from the information gathered by a routing protocol and/or a dependent route queried from RIB through prefix and next-hop registrations. Routing clients may also modify routes based on failure event notifications in order to converge faster, as compared to relying on the routing protocol itself or on RIB updates. The RIB and routing clients are typically considered to be in the “control plane” while the forwarding entities are in the “forwarding plane” (also commonly referred to as the “data plane”).
Routing clients check for reachability before adding their routes and removing/updating them when there is no reachability. Routing clients, however, delegate management of changes to the underlying routes to the RIB. Different routing clients adding routes may end up sharing next-hops in RIB although the routes and paths are different. In such cases, once the RIB has created a next-hop for a route and downloaded it to the forwarding entities, any subsequent routes added that use the same next-hop do not require the next-hop to be re-downloaded again. For example, BGP may add a million routes to a given next-hop. The next-hop, however, is created and downloaded once and subsequently all new routes are downloaded pointing to this next-hop.
As described above, once the RIB has created a next-hop for a route and downloaded it to the forwarding entities, any subsequent routes added that use the same next-hop do not require the next-hop to be re-downloaded again. The RIB, however, does not have the information to determine, at the time of the route addition/update, if there has been a flap or failure event detected in the data plane resulting in a switch-over since the last time the route was updated. Further, although routing clients delegate management of changes to the underlying routes to RIB, there is no mechanism through which the RIB can learn of the flaps or failure notifications that a routing protocol client receives to perform this correctly. Such limitations result in problems where the control plane and data plane go out of sync after a fast switch-over in the data plane resulting in 1) traffic loss due to traffic inadvertently being reverted to a failed primary nexthop, or 2) the forwarding plane staying on the backup path although the primary path is restored on the control plane.